Fix bug that leads to ~23.3% miss rate on kernel32.dll (among others)#71
Open
cyb3rjerry wants to merge 2 commits intoOALabs:mainfrom
Open
Fix bug that leads to ~23.3% miss rate on kernel32.dll (among others)#71cyb3rjerry wants to merge 2 commits intoOALabs:mainfrom
cyb3rjerry wants to merge 2 commits intoOALabs:mainfrom
Conversation
Member
|
just going to double check the original sample first 277d7f450268aeb4e7fe942f70a9df63aa429d703e9400370f0621a438e918bf |
Contributor
Author
|
I can give it a run and post the results here if it can help 👀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hey folks, after working on a Lumma v3 sample I realized the current Murmur2 implementation was giving the wrong hash roughly 23.4% of the time. After a bit of investigation,
72Ghoulon the OALab discord server figured out hashdb's current implementation gives the wrong hash when there is one byte remaining after processing the 4 byte chunks.You can find a diff of kernel32 with the old and new algo (respectively) here: https://www.diffchecker.com/V717U9Cf/
The new implementation is based off https://github.com/Orochimarufan/cdev/blob/master/cdev/murmurhash2.py and has a 0% miss rate. I tested it locally on kernel32.dll, sqlite3.dll and wininet.dll.